[wip]楽しく仕事をするために試行錯誤しているGitHubの使いかた

丹内です。入社してそろそろ3ヶ月になります。

先日のAWS Summitの社内報告会で発表を行いました。

※上記スライドに示された意見はわたし個人のものであり、所属する組織を代表するものではありません。

この発表の最初と最後のGitHubの方が発表した内容の試行錯誤メモブログです。

tl;dr

リモートの人と受託開発をスクラムで進めるにあたり、コミュニケーションをGitHubに集約する試行錯誤中です。

先日のAWS Summit 2015 Tokyoで聴講した「働き方もOSSのようにすることで楽しくなる」という旨の発表に感銘を受け、実務で試みています。

ZenHubとSlackを併用しながら進めています。良い方法や改善点があったら是非指摘してください。

前提

今回は、ソフトウェアの受託開発を想定します。

開発者3,4人が、同じリポジトリで、Railsアプリを開発するとします。

リモートワークの開発者が1人で、あとはフルタイムの開発者です。

GitHub, ZenHub, Slackを使ってスクラムで開発を進めます。

Git Flowにそって開発を進めます。

大まかな開発の流れ

スクラムイベントを行い、タスクボード(物理)を作成する

スプリントのはじめに、スクラムイベントを実施します。

ここで、以下の様なストーリーを全員で考えます。(架空の例です)

ユーザはブログを投稿できる。なぜならhogehogeだから

ユーザは投稿にタグを付けられる。なぜならfugafugaだから

さらに実行レベルでタスクを書き出し、以下の様なタスクボード(物理)を作成します。

タスクボード(物理)は、以下の要素で構成・運用されています。

"PBI"の領域には、ストーリーをポストイットに書いて貼る

"TODO"の領域には、タスクをポストイットに書いて貼る(タスクは、ストーリーに紐付かないものもある)

"WIP"の領域には、現在行っている作業をTODOのなかから選択して貼ります。このとき、自分のタスクであることを示すために、クリップを付けます。

"DONE"の領域には、完了したタスクをWIPから移します。

タスクボード(物理)はオフィスのホワイトボードに貼って設置し、常に更新します。

オフィスにいるチームメンバーは、これを見ることでスプリント中の進捗を一覧することができます。

話を戻して、スプリント中の最初にタスクボードを作成したら、この内容をGitHubに反映します。

タスクボードの内容をGitHubに反映する

ストーリーの内容を、issueに転記します。

What/Why

「誰々は◯◯できる。なぜなら◯◯だから。」というフォーマットに沿って書きます

リモートの人がこれを見て議論したり考えたりできるように、誰に対するどんな価値か、またその根拠を端的に書きます

Acceptance Criteria

ストーリーの受け入れ条件です

Railsアプリの場合、Turnipによるテスト項目と対応するように書きます

Reference

参考になるURLなどがあれば、ここにリンクを張ります

顧客とのやりとり(Wiki)、チーム内でのやりとり(Slack)などが該当します

Task

タスクボード(物理)に書いたものと同じ項目を記載します

チェックボックスにして、進捗によって適宜更新します。

issue一覧から、ストーリーの進捗を以下のように把握できます。

WIP PRを作成して実装を開始する

作業の最初に、空コミットをPushしてWIP PRを作成します。

以下のようにPull Requestを書きます。

Issue

このタスクが紐づくストーリーのIssueを書きます

以下のように、ストーリーのIssueの画面から進捗を確認できます。

コードレビューの後、マージ

作業が終わってCIが通ったら、PRのタイトルから"WIP"を取り外し、Slackやメンションでレビューを依頼します。

レビューや修正が終わったら、マージしてストーリーのissueのTaskを更新して完了です)

積極的に行っていること

コミュニケーションは極力口頭以外で行う

隣の席にチームの人が座っているとついつい口頭で質問をしたくなるのですが、そこをぐっと抑えて極力Slackでやりとりします。

口頭のやりとりで決まったことは、別途しっかりと共有しないとリモートの人がキャッチアップできないため、可能な限りチャットで行うのが望ましいです。

まずIssueを立てて、投げつける

チャットでストレス無くコミュニケーションするには、同じタイミングで相手も座っていなければなりません。

しかしながら、相手がそのタイミングで作業を行っているかは把握しづらいです。

もちろんカメラを繋ぎっぱなしにするという方法もあるのですが、それ以外の方法として、"同期的なコミュニケーションを避ける"という解決策があります。

つまり、最初にIssueを立ててリンクをSlackに流し、時間のあるときに見てもらう、という方法です。

緊急性の高い内容はチャットや音声通話でやりとりしなければならないですが、必要な内容を書いてIssueを立てれば、案外この方法でもやりとりできています。

例えば、仕様の相談をする際、普通なら口頭でやりとりするところを、以下のように進めます。

Issueを立てて勝手にアサインを設定する

SlackでIssueのリンクをメンションする(この後私は外出しました)

仕事に戻ると、以下のように解答されていました。

これを足がかりに仕様を決め、実装を開始しました

課題に感じていること

Labelの運用

ブレブレです。

良い感じの運用方法があったら是非教えて下さい。

tagの運用

使っていません。

いい感じの使い方があったら是非教えて下さい。

PRタイトルにwipとつけること

ZenHubを使っているので、Pipelineで良いのではと思っています。

ただ、GitHubで#と始めた時にタイトルで[wip]と書いていると、わかりやすいんですよね。。。

まとめ

コミュニケーションをGitHubに集約したことで、円滑なコミュニケーションをしながら仕事ができています。

まだ改善点は多いので、改善しながらプロジェクトを進め、新しく成果がでたらこのブログにまとめます。

ご意見ご感想等、ブコメやコメントでどんどんお願いします！

現場からは以上です。